A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Today, there is a growing interest in small or xe2x80x9cform factorxe2x80x9d smart electronic devices. As a result, software applications which were typically the domain of desktop computers are now expected by users to be available on these small devicesxe2x80x94devices which can easily fit in one""s pocket or wallet. Although advances have occurred in software design which provide hand-held devices with substantial processing power, memory capacity, and display power, a number of xe2x80x9cform factorxe2x80x9d related problems nevertheless remain to be solved.
No matter how high the resolution is of a device""s display, for instance, there still remains a finite amount of physical screen xe2x80x9creal estatexe2x80x9d which can be provided by the device. In the case of small hand-held devices, the amount of this screen real estate or physical screen area is obviously much less than that provided by desktop computers. If this problem is addressed by displaying items on screen at a smaller size, users have difficulty reading the information. Although virtual screen technology is available for users to xe2x80x9cpanxe2x80x9d across a larger virtual screen, the additional user input required to manage the process makes the approach undesirable. Information which cannot be seen is of no value to users.
Another problem facing small electronic devices is the difficulty of inputting information. With a small form factor or pocket-size device, it is simply not feasible to include a substantial keyboard for inputting information. Again, the size of the devices reduces the physical surface area available for accommodating input keys or the like. A conventional approach to the problem is to simply build a smaller keyboard, one using miniature input keys. The approach is problematic. In particular, most users find that their fingers are simply too big to use small keys with any degree of efficiency. Further, any efforts to increase the size of a keyboard or keypad in such a device reduces the amount of surface area available for the display screen.
An approach to this problem is to simply let the display screen double as an input device. The basic problem remains unsolved, however. Any display surface area allotted to display screen buttons decreases the amount available for displaying program information, such as output screens. Further, displaying different sets of keys during the operation of a program increases the complexity and, therefore, the learning curve for that program.
A similar approach to the above is handwriting recognition, such as available with Apple""s Newton device. With the current state of handwriting technology, however, the process is both processor intensive (and therefore slow) and error prone. These two disadvantages have combined to make present-day handwriting recognition unattractive to all but the most patient of users. Even with shorthand or gesture-based handwriting recognition, success of those devices remains limited, as most users are unwilling to spend the time mastering gesture strokes.
Again, the physical limitations imposed by these devices remains a problem. For handwriting recognition, for instance, the screen devices must be coated with a special material for receiving stroke input. That material adds yet another layer on top of the display screen thus making the screen more difficult to read (since screen contrast of an already small screen is decreased even further). All told, present-day handwriting recognition is far from an ideal solution.
The problem faced by designers of small xe2x80x9cform factorxe2x80x9d devices is certainly not limited to input and display of information. For instance, a whole set of design problems exist concerning power managementxe2x80x94that is; optimizing a device""s use of a limited power source, such as batteries. All told, the small size of pocket-size devices imposes a physical limitation impacting all the subsystems of such a device.
What is needed is improved user input and usability methodology for small form factor devices. Such a methodology should not require sophisticated hardware support, such as handwriting recognition. Further, such methodology should accommodate a limited or terse set of input keys or buttons (e.g., five keys) as well as limited display surface area typically provided by small form factor devices. Such methodology should nevertheless accommodate large character sets, such as ones including a full range of alphabetic and numeric characters. The present invention fulfills this and other needs.
A portable computing device or xe2x80x9cinformation appliancexe2x80x9d having terse user input (e.g., limit set of keys) is provided with a user interface for navigating user data. The computing device comprises a central processing unit (e.g., microprocessor) connected via a system bus to a display, an input, ports, and memory. Display is a screen device for displaying information, such as a liquid crystal display (LCD) screen. Input comprises a keypad, either physical or logical (e.g., on screen buttons), but limited to a terse set numbering about three to ten buttons and more preferably about five buttons. Memory comprises persistent memory, volatile memory, and non-volatile RAM memory. Persistent memory is typically implemented as a ROM or read-only memory. It stores a single-purpose operating system (SPOS) and application(s). Volatile memory is a xe2x80x9cscratchxe2x80x9d memory, for storing temporary computation results. It typically is implemented as a RAM (random-access memory), for providing a work space for the operating system and applications. Non-volatile RAM memory represents battery-backed RAM memory, for storing context information from one session to another. When the device is powered down the memory stores user data from that session.
The single purpose operating system (SPOS) functions to provide a consistent mechanism by which applications can communicate with the device. In this manner, applications are shielded from hardware complexity, such as hardware interrupts and ports. In other words, it serves to abstract hardware complexity to a high-level application programming interface (API).
Applications are software application programs or modules provided for user operation of the device. The application programs can be implemented as separate modules, which are controlled by a module selector. The module selector serves as a user interface or shell representing the top-level or xe2x80x9chomexe2x80x9d display presented to a user. In the currently-preferred embodiment, the module selector presents the user with selection icons for navigating to different applications or modules of functionality. In an exemplary embodiment, for instance, other modules include a calendar module, a to do module, and an address book module.
In typical use, the device is used in tandem with a desktop computer or PC.
The desktop PC is used by the user when xe2x80x9cat the office,xe2x80x9d and the portable computing device is employed when the user is xe2x80x9con the roadxe2x80x9d (i.e., out of the office). Thus during typical use, large repositories of data reside on the desktop PC which are periodically transferred or synchronized with data residing on the portable computing device. Multiple techniques exist for getting data from the desktop PC to the portable computing device, through device port(s). Using a device input/output (I/O) protocol or standard, such as the PC card standard (formerly PCMCIA standard), the user can easily transfer data to the device via a direct memory transfer. Alternatively, data can be streamed from the desktop PC to the portable computing device via a direct cable (or infrared) connections such as using a serial port-to-serial port connection. Since the data transferred is that of an application operating on the desktop PC, potentially thousands of data items or records might be downloaded into the portable computing device. This potentially large dataset, coupled with the terse key set available at the portable computing device, poses a challenge to the location of desired information by a user. Therefore, improved user interface methodology is needed.
In the most-preferred embodiment, the present invention provides a user interface implementing a xe2x80x9csingle-clickxe2x80x9d style of button operation, so that users can associate each button with a particular task for a given program context. In addition to the single-click style, the preferred embodiment imposes xe2x80x9cclick consistencyxe2x80x9d for each button. Generally, the same buttons are used over and over again to perform their respective tasks, even though the user has navigated to different modules of an application. In this manner, the user is presented with a consistent interface or metaphor which can be easily mastered.
Also in the preferred embodiment, the user interface supports in a small form factor device the browser-style navigation that users have become accustomed to on desktop computers (e.g., using Web browsers). More particularly, the interface supports up, down, forward, and backward (reverse) navigation for allowing a user to xe2x80x9cdrill downxe2x80x9d to xe2x80x9cdrill acrossxe2x80x9d his or her data. This allows the user to find a data item (link) of interest and then drill down into it. Once at the appropriate level, the user can then easily select the particular item of interest. Further, once the user has selected or entered an item, the system provides the ability for the user to return to xe2x80x9chomexe2x80x9d with a single button click. In this manner, the present invention provides an interface allowing browser-style navigation in a device having a terse set of input keys.
A method for providing users with access to applications and user information in a computing device having a limited set of input keys may be summarized by the following method steps. At the outset, the device displays a user interface having a top level view for allowing a user to select among applications available for the computing device. User interface navigation is provided in response to user operation of the limited set of input keys. In response to user selection of a forward key from said limited set of input keys, the device moves a screen cursor in a forward relative direction among screen objects at a given level. In response to user selection of a reverse key from said limited set of input keys, the device moves the screen cursor in a reverse relative direction among screen objects at a given level. In response to user selection of a select key from said limited set of input keys, the device selects a particular screen object at which the screen cursor is currently located, whereupon the device displays a lower level view of the user interface which pertains to the particular screen object. In response to user selection of a home key from said limited set of input keys, the device returns to the top level view. In this manner, access to the applications and user information is achieved for the computing device through use of said limited set of input keys.
Additionally, a device having a terse set of input keys provides password protection as follows. The interface implements a xe2x80x9cgraphical passwordxe2x80x9d which can be entered directly from the terse set of keys. Instead of a conventional alphabetic password as conventionally found on computing devices, the graphical password comprises a sequence of non-alphabetic keystrokes from the terse set. Here, an exemplary graphical password might comprise, for example, FORWARD, FORWARD, BACK, BACK, SELECT, or, alternatively, the user could select HOME, SELECT, FORWARD, HOME, HOME, BACK.
During device operation, upon the user entering a graphical password, the device displays a password entry screen. When the device is configured for password protection, the screen appears each time the device is powered up. To gain access to information on the device, the user must at this point enter the same sequence of key strokes as that which comprises the user""s graphical password. In an exemplary embodiment, a password mask field indicates entries of each key stroke, but with the actual keys themselves being masked.
A method for controlling access to a computing device having a limited set of input keys (particularly, a set of input keys including non-alphanumeric keys) may, therefore, be summarized as follows. At the outset, the device records a user-provided sequence of key strokes entered from the non-alphanumeric keys. The device stores the recorded sequence of key strokes as a xe2x80x9cgraphical passwordxe2x80x9dxe2x80x94that is, a password comprising non-alphanumeric key strokes. Upon request from a user for access to the computing device, the device prompts the user to enter the graphical password. If the user enters a sequence of key strokes which matches that of the sequence of key strokes stored as the graphical password, the device grants device access to the user.
Additional methodology is provided for dynamically adjusting tab categories and subcategories. The method is, in the preferred embodiment driven in part by the number of lines supported by the display. In the foregoing example, for instance, the interface supports seven displayable lines which the user can navigate. The number of displayable lines is employed to set a threshold number of items which must exist before creating further tab categories (i.e., subcategories). In the currently-preferred embodiment, the number is set equal to the number of displayable lines plus 1 (e.g., the number 8, for a display having 7 displayable lines). Any three-letter category which qualifies for subcategory tabs is determined by eight or greater items which satisfy that key. For clarity of the interface, the method adopted always creates a boundary tabxe2x80x94that is, a category tab for the starting index after the subcategory set. In the example presented above, the next tab category created is xe2x80x9cMoxe2x80x9d (instead of the tab category xe2x80x9cNxe2x80x9d), even though the number of xe2x80x9cMoxe2x80x9d entries might be less than the threshold value. By the same token, the methodology ignores combinations which do not exist in the user data. If no xe2x80x9cJxe2x80x9d items exist, for example, then a xe2x80x9cJxe2x80x9d tab is not created. Using the foregoing method, the system provides the user with a xe2x80x9cfindxe2x80x9d operation based, not on a linear search, but on dynamically-created categories.
A method for providing access to a data set which stores information in data records having data fields may, therefore, be summarized as follows. An initial order for displaying the data set based on values of a particular data field is established. Commonly, this will be an alphabetic sort order, such as a descending sort by Last Name. The data set is displayed according to this established order. To facilitate navigation, the device displays category tabs for navigating among individual data records of the data set. This entails the following. The device determines dynamically, based on actual values stored at the particular data field of the data records, categories of information available for the particular data field. Based on this determination, the device displays a tab identifier allowing navigation to a particular category if at least one data item exists for the particular category. In this manner, at least some tab identifiers are eliminated from displayxe2x80x94particularly, tab identifiers are eliminated for those categories of information which currently have no data items. The result is much faster and efficient navigation through large datasets when using a terse or limited key set.